Remarks : 



Reconsideration of the application is respectfully requested. 

Claims 1-11 are presently pending in the application. New 
claim 11 has been added. As it is believed that the claims 
were patentable over the cited art in their previously 
presented form, the claims have not been amended to overcome 
the references. 

In item 6 of the above-identified Office Action, claims 1-3, 
5 and 7-9 were rejected under 35 U.S.C. § 102(b) as 
allegedly being anticipated by W.R. Stevens, "TCP Timeout and 
Retransmission" ("STEVENS") . 

In item 8 of the Office Action, claims 1 - 3, 5 and 7-9 were 
rejected under 35 U.S.C. § 103(a) as allegedly being obvious 
over STEVENS in view of U. S. Patent Application Publication 
No. 2002/0089930 to Aceves et al ("ACEVES") . In item 9 of the 
Office Action, claims 4, 6 and 10 were rejected under 35 
U.S.C. § 103(a) as allegedly being obvious over STEVENS in 
view of U. S. Patent No. 6,222,829 to Karlsson et al 
("KARLSSON") . In item 10 of the Office Action, claims 4, 6 
and 10 were rejected under 35 U.S.C. § 103(a) as allegedly 
being obvious over STEVENS in view of ACEVES, and further in 
view of KARLSSON. 
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Applicant respectfully traverses the above rejections. 

First, as discussed in the Amendment filed on September 15, 
2008 ("the previous Amendment") , in connection with the 
present case, Applicant's claims require, among other things, 
a method or device to perform a slow start algorithm , wherein 
a second number of user data packets from the series of user 
data packets are transmitted to the receiver at a later time 
than the transmission of a first number of user data packets 
from the receiver, wherein "a later time" is defined such that 
it is before a time of receipt of a confirmation of receipt by 
the transmitter of the user data packets . 

However, STEVENS does not disclose or render obvious all of 
the elements of claim 1 . 

Rather, STEVENS describes the TCP Slow Start mechanism. In 
STEVENS, this mechanism has two distinct phases: (1) an 
exponential growth phase; and (2) a linear growth phase. 

During the exponential growth phase of STEVENS, Slow-start 
works by increasing the TCP congestion window each time an 
acknowledgment is received. It increases the window size by 
the number of segments acknowledged. This happens until either 
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an acknowledgment is not received for some segment or a 
predetermined threshold value is reached. If a loss event 
occurs, TCP assumes this it is due to network congestion and 
takes steps to reduce the offered load on the network. Once a 
loss event has occurred or the threshold has been reached, TCP 
enters the linear growth phase in which the window size is 
increased more gradually. 

Referring to Figure 21.2 in STEVENS, the sender initially has 
a window size of one, and sends a first (single) packet at 
point 1. After the first packet has been acknowledged (ack 257 
at point 2) , the window size from the sender is increased to 
two, and so two further packets are sent (one at point 3 and 
one at point 4) . These packets are acknowledged by 
acknowledgements ack 513 and ack 769 (sent at points 5 and 8 
respectively) . Receipt of acknowledgement 513 causes the 
sender to increase its sending window again by one, so that 
the window size is three. However, since there has not yet 
been an acknowledgement received in respect of the packet sent 
at point 4, this means that two user packets are sent (one at 
point 6 and one at point 7) which leaves three packets 
outstanding (i.e. the complete size of the window) . It seems 
that in this implementation, the window size at the sender has 
a maximum of three because subsequent receipt of 
acknowledgement 769 does not cause the sender to increase its 
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sending window further and so only one user packet is sent (at 
point 9) . 

Also in STEVENS, the packets sent from the side identified as 
slip. 1024 and the acknowledgements sent from the side 
identified as vangogh . discard are individual packets and 
individual acknowledgements. They are not groups of packets. 

At best, STEVENS discloses transmitting a first number of user 
data packets (corresponding to the sending of packets at 
points 3 and 4) and transmitting a second number of user data 
packets (corresponding to the sending of packets at points 6 
and 7). Applicant's claims require, among other limitations, a 
confirmation of receipt, transmitted on receipt of the first 
number of user data packets , but received after the second 
number of user data packets are transmitted. However, as is 
clear from the above discussion of STEVENS, in STEVENS, the 
packets at points 6 and 7 are not transmitted before there has 
been received "a confirmation of receipt transmitted on 
receipt of [a] first number of user data packets". 

Rather, in STEVENS, at the time the packets at points 6 and 7 
are transmitted, a confirmation of receipt has, in fact, 
already been received a with respect to the packet sent at 
point 3 of STEVENS. In STEVENS, although an acknowledgement of 
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the packet sent at point 4 is still outstanding when the 
packets at points 6 and 7 are sent, the packets sent at points 
6 and 7 are being sent as a direct response to a confirmation 
acknowledging the receipt of the packet sent at point 3 in 
STEVENS . 

Consequently, STEVENS does not teach or suggest, among other 
limitations of Applicant's claims, a slow start algorithm 

transmitting a second number of user data packets to a 
receiver after the transmission of a first number of user data 
packets, but before receiving at the transmitter a 
confirmation of receipt of the first number of user data 
packets, as required by Applicant's claims. 

Furthermore, STEVENS does not render obvious Applicant's 
claims. STEVENS clearly discloses that a packet is 
transmitted, and, resultantly, an acknowledgement is received, 
wherein the receipt of this acknowledgement results in the 
transmission of a further packet (or further packets) . Thus, 
in the TCP slow start algorithm of Stevens, new packets are 
only being sent in response to an acknowledgement of a 
previously transmitted packet being received. 

Thus, if STEVENS sends a packet while there is still an 
outstanding acknowledgement, the outstanding acknowledgement 
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relates to a separate chain of transmitting packets and 
receiving acknowledgements than triggered the transmission of 
the further packets. In contrast to STEVENS, Applicant's 
claims require transmitting a second number of user data 
packets after the transmission of a first number of user data 
packets, but prior to the confirmation of receipt of the first 
number of user data packets is received by the transmitter. 
Thus, the transmission of the second number of user data 
packets is measured relative to the transmission of the first 
number of user data packets (i.e., after their transmission, 
but before receiving confirmation of their receipt), and is 
not merely to a randomly chosen one previously transmitted 
packet . 

The STEVENS TCP Slow Start mechanism provides a rapid ramp-up 
of sending data packets within the constraints of receiving 
acknowledgements for individual packets. As such it contains 
no teaching or suggestion that a second number of user data 
packets is transmitted at a later time than a first number, 
but before the confirmation of receipt of a first number has 
been received. To modify STEVENS to include such a feature 
would impermissibly render the device of STEVENS inoperative 
for its intended use. See, for example, M.P.E.P. § 2143. 01 (V) . 
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In response to Applicant's previously made arguments, item 4 
of the present Office Action stated, in part: 



Examiner respectfully disagrees with Applicant's 
interpretation of the prior art. Stevens, in Figure 
21.7 , makes clear that a second number of user data 
packets (those transmitted from slip. 1024 at 54 and 
55) are transmitted before there has been received a 
confirmation of receipt transmitted on receipt of a 
first number of user data packets (confirmation of 
packets transmitted from slip. 1024 at 50 and 52 is not 
received by slip. 1024 until much later [note that the 
diagram is slightly different due to the lost segment 
45, which causes duplicate acks]). [emphasis added by 
Applicant] 



However, it should be noted that Applicant's claims recite a 
slow start algorithm . Although Stevens includes disclosure of 
a slow start algorithm, this disclosure is with respect to 
Figure 21.2 of STEVENS. See, for example, the end of section 
21.4 of STEVENS (i.e., "We described the slow start algorithm 
in Section 20.6. We can see it in action again in Figure 
21.2."). Thus, Fig. 21.7 of STEVENS, pointed to in item 4 of 
the Office Action, does not relate to a slow start algorithm, 
but rather, relates to a subsequent data transmission, 
described, for example, in connection with Figure 21.6 of 
STEVENS (i.e., "We can immediately see the three 
retransmissions around times 10, 14, and 21 in Figure 21.6. At 
each of these three points we can also see that only one 
segment is retransmitted, because only one dot dips below the 
upward slope. Let's examine the first of these dips in detail 
(around the 10-second mark) . From the tcpdump output we can 
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put together Figure 21.7.") Note that STEVENS actually 
describes Figure 21.6 as "Packet exchange for retransmission 
around the 10-second mark." 



Section 4 of the Office Action further alleged, in part: 



In response to applicant's argument that the 
references fail to show certain features of 
applicant's invention, it is noted that the features 
upon which applicant relies (i.e., that a receipt is 
not transmitted after every packet, but only after a 
number of packets) are not recited in the rejected 
claim (s) . 



However, Applicant did not make the argument alleged above. 
Rather, in the previous Amendment, Applicant stated, in part: 



However, claim 1 recites that sending of the first 
number of user data packets is related to the sending 
of the second number of user data packets by a 
confirmation of receipt in respect of the first number 
of user data packets, not in relation to one previous 
packet. [emphasis in original] 



Item 4 of the Office Action additionally stated, in part: 



Examiner agrees that Stevens does not explicitly 
disclose delayed acknowledgements. However, this 
feature is explicitly disclosed by Aceves [Paragraph 
0044], among others, who states that delayed 
acknowledgements are an inherent part of the TCP 
protocol. Moreover, under the standard TCP 
implementation, as explained by Stevens, packet 
acknowledgements are cumulative - an ack for packet 
N+l inherently acknowledges packets 1..N as well. 

However, the above-quoted portion of item 4 of the Office 

Action does not point out with particularity how the concept 
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of "delayed acknowledgements" allegedly applies to Applicant's 
claimed invention. 



On page 4 of the Office Action, item 4 of the Office Action 
further states, in part: 



Applicant alleges that modifying the Stevens TCP Slow 
Start mechanism with delayed or cumulative 
acknowledgements "would render the device inoperative 
for its intended use. 



Applicant's respectfully point out that the foregoing 
statement is an inaccurate and out-of-context summation of the 
statement made in the previous Amendment . In that previous 
Amendment, as well as herein, Applicant stated, in part: 



The Stevens TCP Slow Start mechanism provides a rapid 
ramp-up of sending data packets within the constraints 
of receiving acknowledgements for individual packets. 
As such it contains no teaching or suggestion that a 
second number of user data packets is transmitted at a 
later time which is before a confirmation of receipt 
of a first number of user data packets has been 
received. To modify Stevens to include such a feature 
would render the device inoperative for its intended 
use . 



As can be seen, Applicant put forward an argument that it 
would not have been obvious to modify the slow start of 
Stevens to produce claim 1. In response to Applicant's above- 
quoted argument, item 4 of the Office Action alleged, in part: 



There is no reason to believe that slow start and 
delayed/cumulative acknowledgements are incompatible. 
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Item 4 of the Office Action goes on to point to paragraph 
[0044] of the ACEVES reference, among other references, as 
allegedly teaching a combination of slow start and 
delayed/cumulative acknowledgements. As will be discussed more 
fully herebelow, Applicant fails to see a relationship between 
paragraph [0044] of ACEVES and Applicant's claimed invention. 

With regard to the rejections of Applicant's claims 1 - 3, 5 
and 7-9 made in item 6 of the Office Action, Applicant notes 
that the Examiner is making arguments by selectively picking 
features of different devices of STEVENS and combining them. 
However, it is not so simple to, in fact, combine the selected 
features in the manner suggested in the Office Action. In 
particular, the Office Action first refers to section 21.4 of 
STEVENS, while discussing the disclosure of a slow start 
algorithm in STEVENS. The Office Action then goes on to mix 
together two different disclosures of STEVENS, i.e., the 
disclosure in section 21.2 of STEVENS and the disclosure in 
section 21.7 of STEVENS. However, with respect to Figure 21.2 
of STEVENS, the Office Action puts forward the same arguments 
to which Applicant replied in the previous Amendment. 

As discussed above and in the previous Amendment, Applicant's 
claims require, among other limitations, a transmission of a 
first number of user data packets to the receiver, followed by 
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a transmission of a second number of user data packets to the 
receiver at a later time, but before the transmitter receives 
from the receiver a confirmation acknowledging receipt of the 
first number of user data packets . 

STEVENS simply cannot disclose this feature of Applicant's 
claims because, as discussed above, the packets sent at points 
6 and 7 of STEVENS are sent at a time when: (i) an 
acknowledgement has been received with regard to the packet 
sent at point 3 of STEVENS; and (ii) an acknowledgement has 
not been received with respect to the packet sent at point 4 
of STEVENS. As such, STEVENS teaches, in fact, transmitting 
the packets sent at points 6 and 7 of STEVENS in direct 
response to a confirmation of the receipt of the packet sent 
at point 3 of STEVENS, and thus is contrary to Applicant's 
claimed invention, regardless of what happens with the packet 
sent at point 4 of STEVENS. 

Further, section 21.7 of STEVENS, pointed to in the Office 
Action, does not relate to a slow start algorithm, as 
discussed above. Thus, the discussion in section 21.7 of 
STEVENS is not combinable with the embodiments of STEVENS that 
do actually relate to a slow start algorithm. The mixing and 
matching of different embodiments of STEVENS, only some of 
which even relate to a slow start algorithm, does not teach or 
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suggest Applicant's claimed invention. Rather, the inventions 
described in STEVENS in connection with Figures 21.2 and 21.7 
are different and distinct from one another, the elements of 
which are not combinable in the manner suggested in the Office 
Action without changing the principle of operation of one or 
the other embodiments. See, for example, M.P.E.P. § 
2143.01 (VI) . 

In particular, Applicant notes that it would not be obvious to 
a person of ordinary skill in this art to swap features 
between a device performing a slow start algorithm and a 
device performing a normal steady-state transmission. Rather, 
a slow start algorithm is particularly configured to deal with 
uncertainties that might exist in a connection. In a slow 
start algorithm, when a connection is established, TCP starts 
slowly at first, so a transmitter can assess the bandwidth of 
the connection and avoid swamping a receiver or any other 
devices or links in the connection path. As such, in a slow 
start algorithm, instead of immediately sending enough data 
which might possibly swamp a receiver during the initial phase 
of communication, the transmitter transmits a conservative 
amount of data and gradually increases it as the transmitter 
discovers more about the performance of the communications 
path. This gradual increase is performed by the transmitter 
increasing a window each time an acknowledgment is received. 
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In particular, the transmitter increases the window size by a 
number of segments acknowledged. In a slow start system, this 
process is repeated until either an acknowledgment is not 
received for some segment, or until a predetermined threshold 
value is reached. The slow start algorithm was created for a 
particular purpose and to achieve a particular result, and 
thus, has a different principle of operation from a system 
performing normal steady-state transmission. 

As such, it would not be obvious for a person of ordinary 
skill in this art to put a slow start feature into a steady- 
state system, or vice-versa. Rather, the STEVENS reference 
would require an explicit teaching to make the combination 
suggested in the Office Action, in order for a person of 
ordinary skill in this art to even think to incorporate a 
feature from the normal steady-state transmission described in 
connection with Figure 21.7 of STEVENS into the slow start 
algorithm described in connection with Figure 21.2 of STEVENS. 
STEVENS does not provide such a teaching. 

In addition to alleging that STEVENS anticipates Applicant's 
claims 1 and 8, item 8 of the present Office Action 
additionally rejects claims 1 and 8 as allegedly being obvious 
over STEVENS in view of ACEVES . However, as was done in item 
6 of the Office Action, the arguments present in item 8 of the 
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Office Action impermissibly mix-and-match the disclosures from 
two different and distinct embodiments of STEVENS, i.e., that 
of Figures 21.2 and 21.7 of STEVENS. The ACEVES reference, 
however, does not cure this problem of the STEVENS reference. 

More particularly, page 8 of item 8 of the Office Action 
acknowledged that STEVENS did not explicitly disclose 
receiving a "single" confirmation of receipt for the first 
number of user data packets. Rather, the Office Action 
pointed to paragraph [0044] of ACEVES as allegedly teaching 
receiving a "single" confirmation of receipt for the first 
number of user data packets. However, the receipt in ACEVES 
of a single confirmation for a plurality of user data packets 
is irrelevant to curing the deficit in the teachings of 
STEVENS with regard to Applicant's claimed invention. 
Applicant's claimed invention relates to, among other things, 
the transmission of a second number of user data packets after 
the transmission of a first number of user data packets, but 
prior to receiving confirmation that the first number have 
been received. ACEVES does not teach or suggest, among other 
limitations of Applicant's claims, a slow start algorithm 
having the particularly recited timing of the transmission of 
the second number of user data packets, as particularly 
recited in Applicant's claims. This feature of Applicant's 
claims is not disclosed in connection with the slow start 
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algorithm embodiment of STEVENS (i.e., Fig. 21.2 of STEVENS), 
nor is it disclosed by ACEVES. Thus, the disclosure in ACEVES 
of receiving a "single" confirmation of receipt for a number 
of user data packets would not teach, suggest or motivate a 
person of ordinary skill in this art to modify the slow start 
algorithm described in connection with Figure 21.2 of Stevens 
to produce Applicant's particularly claimed invention. 
Similarly, the disclosure in ACEVES of receiving a "single" 
confirmation of receipt for a number of user data packets 
would not teach, suggest or motivate a person of ordinary 
skill in this art to modify the non -slow start algorithm 
described in connection with Figure 21.7 of Stevens to produce 
Applicant's particularly claimed invention. Put quite simply, 
the disclosure in STEVENS of the device of Figure 21.7 of 
STEVENS does not relate to a slow start algorithm and, 
therefore, portions of the invention of Figure 21.7 of STEVENS 
cannot simply be lifted out of that invention and dropped into 
the different and distinct invention of another figure of 
STEVENS without any teaching, suggestion or motivation to do 
so. Nothing in the ACEVES reference (in paragraph [0044] or 
elsewhere) provides such a teaching, suggestion or motivation 
to a person of ordinary skill in this art to impermissibly 
alter the principle of operation of the embodiment of Figure 
21.2 of STEVENS with a feature disclosed in connection with a 
different and distinct invention of a different figure of 
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STEVENS. Put quite simply, nothing in ACEVES' disclosure of 
paragraph [0044] would lead a person of ordinary skill in this 
art to modify Figure 21.7 of STEVENS in any way that would 
produce Applicant's particularly claimed slow start algorithm. 

For the foregoing reasons, among others, Applicant's claims 
are believed to be patentable over the STEVENS and ACEVES 
references. The KARLSSON reference, cited in the Office 
Action in combination with STEVENS and ACEVES against certain 
of Applicant's dependent claims, does not cure the above- 
discussed deficiencies of the STEVENS and ACEVES references. 

It is accordingly believed that none of the references, 
whether taken alone or in any combination, teach or suggest 
the features of claims 1, 8 and 11. Claims 1, 8 and 11 are, 
therefore, believed to be patentable over the art. The 
dependent claims are believed to be patentable as well because 
they all are ultimately dependent on claims 1 or 8 . 

In view of the foregoing, reconsideration and allowance of 
claims 1-11 are solicited. 

In the event the Examiner should still find any of the claims 
to be unpatentable, counsel would appreciate receiving a 
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telephone call so that, if possible, patentable language can 
be worked out. 

Additionally, please consider the present as a petition for a 
two (2) month extension of time, and please provide a two (2) 
month extension of time, to and including, April 27, 2009, to 
respond to the present Office Action. 

The extension fee for response within a period of two (2) 
months pursuant to Section 1.136(a) in the amount of $490.00 
in accordance with Section 1.17 is enclosed herewith. 

Please provide any additional extensions of time that may be 
necessary and charge any other fees that might be due with 
respect to Sections 1.16 and 1.17 to the Deposit Account of 
Lerner Greenberg Sterner LLP, No. 12-1099. 

Respectfully submitted, 

/Kerry Pauline Sisselman/ 
Kerry Pauline Sisselman 
Reg. No. 37,237 

For Applicant 

April 27, 2009 

Lerner Greenberg Sterner LLP 
Post Office Box 2480 
Hollywood, FL 33022-2480 
Tel: (954) 925-1100 
Fax: (954) 925-1101 
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